Skip to content

fix(test): do not assert a POSIX execute bit on Windows - #119

Merged
abrichr merged 1 commit into
mainfrom
fix/ffmpeg-test-windows-mode
Aug 28, 2026
Merged

fix(test): do not assert a POSIX execute bit on Windows#119
abrichr merged 1 commit into
mainfrom
fix/ffmpeg-test-windows-mode

Conversation

@abrichr

@abrichr abrichr commented Aug 28, 2026

Copy link
Copy Markdown
Member

test-windows went red on main after #118.

test_install_writes_verified_files_and_a_receipt asserted st_mode & 0o100
on the installed ffmpeg. Windows has no execute bit. st_mode reads 0o666 or
0o444 there and chmod only toggles the read-only flag, so the assertion
could never hold on that platform.

The installer itself is fine on Windows. ffmpeg-pin.yml's install-and-encode
lane passed on windows-latest in #118: it downloads the pinned archive,
verifies every digest, installs, and runs a real encode-and-decode probe. That
lane proves the property this assertion was reaching for.

So the mode checks stay on POSIX, where they mean something, and Windows checks
readability instead. The digest-ordering test is untouched and still runs on
every platform.

🤖 Generated with Claude Code

test_install_writes_verified_files_and_a_receipt asserted st_mode & 0o100 on
the installed ffmpeg. Windows has no execute bit: st_mode is 0o666 or 0o444
there and chmod only toggles read-only, so the assertion could never hold and
test-windows went red on main after #118.

The install-and-encode lane in ffmpeg-pin.yml already proves the installed
runtime actually runs on windows-latest, which is the property this assertion
was reaching for. Keep the mode checks on POSIX and check readability on
Windows.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@abrichr
abrichr merged commit 9f8672c into main Aug 28, 2026
12 checks passed
@abrichr
abrichr deleted the fix/ffmpeg-test-windows-mode branch August 28, 2026 18:00
abrichr added a commit that referenced this pull request Aug 28, 2026
#118 and #119 landed after the 1.3.0 section was written, so the notes
did not mention them. #118 in particular adds a user-facing command and
a network fetch, which the notes must state.

The FFmpeg entry says plainly that neither artifact carries FFmpeg bytes
and that nothing downloads unless the operator asks. Verified against the
built wheel and source archive rather than taken from the commit message.

The version stays 1.3.0. The highest bump implied since v1.2.2 is still
minor, and 1.3.0 is already the minor.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant